[神ツール]セキュリティインシデントの調査が捗るAmazon DetectiveがGAしたのでメリットとオススメの使い方を紹介します

インシデントの調査がとっても捗るAmazon Detectiveについて、どのような役割とメリットがあるのか、使い方の勘所、そのコスパについてまとめました。これも全アカウント必須ですよ！

#セキュリティ

#Amazon Detective

#Amazon GuardDuty

#AWS

臼田佳祐

2020.04.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、インシデントの調査してますか？(挨拶

ついに待ちに待ったAmazon Detectiveが正式リリースされました！セットアップの方法は下記にありますので、ぜひGuardDutyと同じように対応しているすべてのリージョンで有効化しましょう。

で、本記事ではそもそもどのように調査が捗るのか？とかどんな機能があるんだっけ？というところを整理して、「あーすべての環境で有効化したほうがいいな、これ」と思ってもらえるように伝えていこうと思います。

Amazon Detectiveの役割とメリット

まずは公式の製品ページの説明文を見てみましょう。

Amazon Detective では、潜在的なセキュリティ問題や不審なアクティビティの根本原因を簡単に分析、調査し、すばやく特定できます。Amazon Detective は、AWS リソースからログデータを自動的に収集し、機械学習、統計的分析、グラフ理論を使用して、リンクされたデータセットを構築します。これにより、より迅速かつ効率的なセキュリティ調査を簡単に行えます。

Amazon Detective - アマゾンウェブサービス

例のごとくよくわからないと思います。頭に入ってきませんね。

Detectiveは調査をするツールという感じですが、これを理解するにはセキュリティインシデントが発生した際の調査のイメージを持つことが必要です。というわけで下記をご覧ください。

これはre:Invent2019で行われたDetectiveお披露目時のセッション資料です。セキュリティの対応フローが左から右に流れていて、真ん中のインシデントを検知する部分はGuardDutyやSecurity Hubで実施をしています。そして、検知したらそのインシデントがどれくらい危ないものなのか、誰がいつどのような操作を行ったのか、その前後にどのようなことが発生しているのかを調べる必要があります。このフェーズが調査ですね。

これまでは、どのユーザーが操作したかはCloudTrail、EC2やVPC内のリソースが内部や外部とやり取りしたトラフィックのログはVPC Flow Logsで出力されていて、それぞれのコンソールやCloudWatch Logs・S3に保存されたログをフィルターやクエリをかけて探したりしていました。S3に保存している場合にはログファイルは細かく分割されているので、Athenaを使ってクエリをかけて、CSVで出力して細かい調査はエクセルでやる、みたいなこともよくありました。

具体的に見たいことは、GuardDutyで検知した内容の詳細を確認することです。例えば「IAM Userが普段とは違うところから利用されている」というインシデントが検知された際には下記のようなことが確認したくなります。

IAM Userが普段どのIPから利用されているか
普段と違う場所とはどこか？(IP and 国などの地域情報)
普段と違う場所からどの操作を行ったか
作成されたEC2などがあるか(第三者に盗まれている場合、コインマイニングのために沢山EC2を立てられる)

GuardDutyの検知結果では、対象のIAM Userや普段と違うIPを1つ、そのイベントが何回ぐらい発生しているかはわかりますが、関連する操作やEC2や多数のIP、どれくらいIAM Userが使われているかなどはわからないためAthenaでCloudTrailのログにクエリをかけて取得し、目で見ていくことになります。データはCSVなので関連するリソースや操作を調べるためにはフィルターをかけたり外したり、同じ表を複数のシートにコピーして使い分けたり、目で確認して考えてエクセルこねこねしていきます。つらみ。

というわけで長々と説明しましたが上の図の調査フェーズでは書かれているサービスも利用しますが、それ以上に手や目や勘で補う部分が非常に多いのです。

このフェーズをがっぽり置き換えたものが下記の図です。

はい、わかりやすいですね。

これまで説明した調査作業は全部Detectiveの画面上で簡単に操作・確認することが可能です。

Detectiveではイベントやリソースなどの各種エンティティがグラフモデルで保存されます。単純な2次元の表ではなくエンティティ間の関連を持たせて保存されているので、関連情報を簡単に表示、可視化できます。これによりGuardDutyのFindingsに対応するIAM Userは？そのIAM Userに関連するIPアドレスは？関連するEC2インスタンスは？など簡単に辿ることができます。

また、全部Detective上でと説明しましたが、GuardDutyのイベントを始めCloudTrailやVPC Flow Logsは、Detectiveを有効化したら自動的に収集されグラフにまとめられます。分散したログを見る必要もなければ、収集する仕組みを別途作る必要もありません。すぐに始められます。そして、マルチアカウントで集約して調査することもできます。すばらしい。

Detectiveの役割とメリットについて説明してみましたがいかがでしょうか？後は実際に見てみたほうがわかりやすいと思うので画面を見てイメージを固めてください。

オススメの使い方

というわけで役割やメリットはなんとなく理解できたと思いますが、具体的に見てみないとよくわからないと思うので画面と一緒にオススメの使い方を紹介します。下記2点を中心に説明していきます。

調査はGuardDutyから始める
スコープをロックする

なお、Detectiveの有効化については先述したリリース時のブログをご確認ください。

1. 調査はGuardDutyから始める

Detectiveでの調査は主にGuardDutyでインシデントを検知してから始まります。というわけでGuardDutyの画面から始めます。

検知したFindingsを選択して、左上の「アクション」から「調査」を選ぶとDetectiveの画面へ移動できます。移動する前についでにFindingsの概要はGuardDutyで確認しておくといいでしょう。

なんでわざわざGuardDutyから飛ぶかということですが、下記Detectiveの画面をご覧ください。

メインのエンティティを確認するページはSearchですが、このページではエンティティのタイプとIDを入力しないと詳細情報を得られず、一覧をリストで表示するような機能が今はありません。そのため、この画面に来てからGuardDutyのFindingsを探そうと思っても、Findings IDがわからないため調査したいイベントに辿り着くことができません。Detectiveを使い始めたときの最初の罠なので注意が必要です。

GuardDutyから調査で飛んできたら最初から下記のようにFindingsが調査された状態で出てきます。Findingsでは、その中心となっているリソースについて表示されます。今回はRecon:IAMUser/UserPermissionsというFindingsで、IAM Userが普段行わない権限の操作を行った場合に検知されるもので、該当するIAM Userについての調査結果が表示されています。対象がIAM RoleのFindingsならここはIAM Roleに変わります。

タブが4つありますが、左2つが対象リソースについて、右2つは対象のアカウントについての情報になります。まずは一番左のOverviewを見ていきます。Findingsの詳細が最初に表示されていて関連リソースが表示されています。関連リソースはリンクになっていますが、これを押せばそのリソースに関するDetectiveの調査画面が表示されます。どんどん辿れます。

下の方には対象ユーザーの詳細や関連するGuardDuty Findingsが出てきます。ユーザーの作成者やいつ作られたかがすぐわかるのはいいですね。作成されたすぐに操作されたのか、時間が経っているのかなどもわかります。関連するFindingsは他のインシデントとのユーザーの関連がわかります。もっと危ないインシデントと繋がっていたら、そのユーザーは要注意でしょう。

更に下には該当ユーザーが行ったAPIコールの成功と失敗の時系列グラフがあります。失敗情報は非常に役に立ちます。攻撃者の場合、権限昇格や不正な操作をしようとして失敗しているなどの形跡が見られます。

更にこのグラフでは、特定の時間を選択するとAPIコールの内訳がIP毎、API毎、アクセスキー毎に見ることができて、それぞれドリルダウンできます。IPベースで見ると、そのIPからどのAPIが実行されているかが次に見れます。例えば特定のIPで権限の強いAPIが大量に失敗が発生していたらめちゃくちゃ怪しいですね。ちなみに今回はパスワード変更とMFA設定を行っていて正常系の操作ですが、これまで使われていなかったことと、権限が強いこともあって検知されているようです。

IPについて見ることができましたが、これをもっとわかりやすく見れるのは2つ目のタブのbehaviorの部分です。画面上に戻ってこれを表示してみます。すると地図上に利用状況がマッピングされました。今回は1つのIPしか無いので1つしか丸がありませんが、例えば日本のユーザーなのにアメリカにも丸があったら怪しいですよね。それが一発でわかります。この画面でもIPを選んでいくとそれに紐づくAPI操作を確認できます。

このような感じで該当リソースに関する情報と、その関連リソースへのリンクが用意されているのでこの画面上で必要な調査はほとんどできそうです。

ちなみにタブの右2つのアカウントについての情報は、アカウント全体のものになるので直接調査に必要ないノイズも結構入っていたりします。メインを左2つのターゲットリソース関連情報で確認し、アカウント全体のものは参考程度にしましょう。

2. スコープをロックする

続いて関連リソースを辿るときの注意事項です。右上にScope timeというものがありここで対象とする時間範囲を決めています。その時間枠の中の関連イベントやリソースが表示されているので、調査を行う上では非常に重要です。

Findingsの画面ではある程度発生時の時間に合わせてありますのでそのままで大丈夫ですが、関連リソースに移動する際には先にここのLockをOnにしてから移動してください。これをしないとScopeがリセットされて最近の状況が表示されるようになります。

ここでは例としてIPリソースについて遷移してみます。Lockしていると下記の通り同じ時間のまま遷移することができています。どの時間について表示しているかは常に気をつけてください。

IPの画面ではまた表示内容が違います。この画面でのオススメはResource interactionで関連するリソースが表示されます。EC2に関連するIPであればここでいつからやり取りしているかなどが辿れるのでここも見ていくといいです。

さて、実際の画面を用いてオススメの使い方を紹介しました。だいぶ捗り具合を感じられたのではないかと思います！

Detectiveの料金について

最後に料金についての参考情報です。便利なことはわかっても、高かったら使うのを渋ってしまいますよね？

ちなみにDetectiveの前提であるGuardDutyについては下記を見ていただくと非常にわかりやすいと思います。コスパ最強なんです。

で、上記記事にも書かれていますがGuardDutyはAWS全体の利用費の1%に満たないことが大多数です。これよりは断然EC2などのリソースのほうが料金がかかります。

GuardDutyの料金体系(バージニア)は下記のようになっています。

VPC フローログと DNS ログ分析
- 最初の 500 GB/月 GB あたり 1.00USD
- 次の 2000 GB/月 0.50USD/GB
- 次の 7,500 GB/月 0.25USD/GB
- 10,000 GB/月を超えた場合 0.15USD/GB
AWS CloudTrail イベント分析
- イベント 100 万件/月イベント 100 万件あたり 4.00USD

一方でDetectiveの料金体系は下記のようになっています。

AWS CloudTrail、Amazon VPC Flow Logs、Amazon GuardDuty から取り込まれたデータ
- 最初の 1,000 GB/アカウント/リージョン/月 2.00 USD/GB
- 次の 4,000 GB/アカウント/リージョン/月 1.00 USD/GB
- 次の 5,000 GB/アカウント/リージョン/月 0.50 USD/GB
- 10,000 GB 以上/アカウント/リージョン/月 0.25 USD/GB

GuardDutyと違いCloudTrailも一緒にデータ量で見ていたり、新しくGuardDutyのデータを入れている代わりにDNSログがなくなっているので一概には言えませんが、一番最初の料金のところでいうとGuardDutyの2倍程度の料金です。

非常にざっくりですがGuardDutyの料金が3倍になるくらいで考えてもいいかもしれません(かなり強引

3倍って考えると結構高く感じてしまいますが、元々全体の1%にも満たない金額のものなのでそこまでではないでしょう。

加えて、Detectiveを使わないで調査をしたらAthenaでクエリをかけたりするので、そこで分析するログの量でAthenaの料金もかかってくるのでその分の費用と、工数を補っていると考えると悩む必要もないと思います。

更に30日間の無料枠もあるので実際にどの程度の費用が発生するかも確認できます。DetectiveのUsage画面で確認しましょう。